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ELECTRONIC COMMERCE SYSTEM 
jJViU 1 ^" 1 Reference to^ Appendices 

^Fcx - tr Appendicesy^A-C are included with this patent 
application. $ 

Background of the Invention 

This invention relates to electronic commerce 
systems implemented using public packet switched 
communications networks . 

U.S. Patent No. 5,724,424, the entire disclosure of 
which is hereby incorporated herein by reference, filed 
December 16, 1993 by David K. Gifford and issued on March 3, 
1998, discloses an electronic commerce system that allows 
buyer computers to purchase goods or information from 
merchant computers over a public packet switched 
communications networks. The merchant computers cause 
electronic documents to be sent to buyer computers 
containing forms that buyers can fill out and return to the 
merchant computers to request purchases. A payment computer 
obtains authorization of payment orders for purchases in 
real time from an external financial authorization network. 

Summary of the Invention 

One aspect of the invention provides an electronic 
commerce system that includes a client computer and a server 
computer interconnected by a public packet switched 
communications network. The client computer is programmed 
to transmit to the server computer an order acceptance 
request that includes a plurality of terms or conditions of 
a proposed offer for a purchase, including multiple options 
of at least one of the terms or conditions of the offer. 
The server computer is programmed to process the order 
acceptance request based on pre-programmed criteria and, 
based on the processing of the order acceptance request, to 
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transmit to the client computer an order acceptance response 
that includes amendment to the proposed offer for the 
purchase. The amendment includes selection of an option of 
the at least one of the terms or conditions. 
5 According to another aspect of the invention, the 

order acceptance response includes a plurality of amendments 
to the proposed offer for the purchase. 

According to another aspect of the invention, the 
order acceptance request includes a plurality of modular 
10 element^_individually protected by cryptographic "security 
codes. The server computer is programmed to authenticate 
the cryptographic security codes and to examine the modular 
elements individually protected by the cryptographic 
security codes. 

15 According to another aspect of the invention, the 

processing of the order acceptance request is performed by a 
controller module that handles processing of the order 
acceptance request that is primarily not specific to a 
particular application of the electronic commerce system to 

2 0 which the order acceptance request pertains, and that 

initiates a plurality of calls to a plurality of plug-in 
modules. The plug- in modules handle processing of the order 
acceptance request that is primarily specific to the 
particular application of the electronic commerce system, 
25 and can be readily replaced by different plug- in modules 
that handle processing primarily specific to different 
applications of the electronic commerce system. 

According to another aspect of the invention, the 
server computer f urther^ei^g programmed to handle fraud- 

3 0 avoidance processing of the order acceptance request based 

on contents of the order acceptance request other than 
price, purchaser identity, and seller identity. 
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According to another aspect of the invention, the 
server transmits to the client computer an order acceptance 
response comprising amendment to the proposed offer for the 
purchase, where the amendment includes an amended price 
5 based on terms or conditions recited in the order acceptance 
request that are less than optimal based on the pre- 
programmed criteria. 

According to another aspect of the invention, the 
server initiates a call to a database of a virtual warehouse 
10 in which merchants store virtual inventories of items, to 
ensure that a sufficient virtual inventory exists for the 
purchase . 

According to another aspect of the invention, one of 
4f the client computers is programmed to transmit to the server 

f% 15 computer a first order acceptance request that includes a 
Ul plurality of terms or conditions of a proposed offer for a 

ZI purchase of a gift certificate. Another of the client 

03 computers is programmed to transmit a second order 

J" acceptance request that includes the gift certificate. The 

D . 20 server computer is programmed to store gift certificate 
T information in a database when it receives the first order 

M: acceptance request and to examine the database when the 

^ server computer receives the second order acceptance 

request . 

25 According to another aspect of the invention, the 

proposed offer is for a purchase of tokens to be redeemed 
for micro-purchases, and the server computer is programmed 
to increase a number of tokens in a token database that are 
available for use in exchange for the micro-purchases. 

30 According to another aspect of the invention, the 

proposed offer is for a purchase of a subscription, and the 
server is programmed to update a subscription table in order 
to reflect the purchase of the subscription. 
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Numerous additional features and advantages of the 
invention will become apparent from the detailed 
description, drawings, and claims. 

Brief Description of the Drawings 
5 FIG. 1 is a block diagram of an electronic commerce 

system according to the invention. 

FIG. 2 is a flow-chart diagram of the order 
acceptance controller and order capture controller of the 
electronic commerce system of FIG. 1. 
10 FIG. 3 is a block diagram of a fraud avoidance 

controller system for use in the electronic commerce system 
of FIG. 1. 

FIG. 4 is a block diagram of an inventory 
availability controller system for use in the electronic 
15 commerce system of FIG. 1. 

FIG. 5 is a block diagram of a shipping restriction 
plug- in system for use in the electronic commerce system of 
FIG. 1. 

Detailed Description 

2 0 With reference to FIG. 1, the invention provides an 

electronic commerce system 10 that enables automated 
processing of on-line orders using advanced order 
acceptability criteria. The electronic commerce system 
negotiates with client computers 12, which may be operated, 
25 for example, by buyers who wish to purchase goods or 

services, or by agents who make purchase for or make sales 
to buyers. Once the negotiation phase is complete, or 
independently thereof, the electronic commerce system can 
enter a transaction phase in which an order by client 

3 0 computer 12 for goods or services to be delivered by a 

seller is "captured" by server 14. 

According to the negotiated order acceptance 
protocol of electronic commerce system 10, client computer 
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12 first sends an order acceptance request message 16 to 
server 14 . Order acceptance request 16 may contain 
information identifying the buyer (which may or may not be 
the client), the seller, the goods, products, or services 
5 that the buyer wishes to purchase, optional information 

describing terms or conditions of the purchasing transaction 
that the client considers desirable, and unique order- 
identifying information for use by client computer 12 and 
server 14 to speed order processing and for use in 
10 identifying the order in other related protocols. Such 

terms or conditions may include intended means of payment, 
time of payment, payment guarantee conditions, shipping 
methods, time and place of delivery, insurance coverage, 
^ risk-of-loss provisions, cancellation policies, goods 

Q 15 acceptance criteria, and other terms. In a particular 
^ Ul embodiment, header files useful in implementing the protocol 

described above are shown m portions of^ Appendix B. 
EC Server 14 processes order acceptance request 16 and 

~- generates an order acceptance response 18 containing the 

O 2 0 original order acceptance request amended to indicate the 
^ terms or conditions acceptable to server 14 and which may 

M- contain unique order-identifying information. These 

^ amendments signify that certain terms or conditions 

un- 
specified in, or omitted from, order acceptance request 16 

25 constitute violations of the server's order acceptance 

criteria. The amendments include a list of specific order 
acceptance criteria, each of which indicates specifically 
the section of the original order acceptance request to 
which it refers and indicates alternative choices that would 

30 be acceptable to server 14. An amendment may -indicate that 
server 14 rejects a specific term or condition and may 
contain a menu of proposed replacement terms, or an 
amendment may refer to an element of the proposed order that 



was omitted from order acceptance request 16 and may propose 
a menu of acceptable terms or conditions for that element. 

Order acceptance request 16 may optionally contain 
client approval status information. For example, the client 
5 approval status information may indicate that the client 
wishes to obtain the server's opinion of order acceptance 
request 16, to be expressed in the form of an order 
acceptance response 18 that includes remarks from server 14, 
as part of the negotiation phase of the electronic commerce 
10 transaction. Upon receipt of order acceptance response 18 
from server 14, the client is free to abandon the 
transaction, to incorporate the server's changes into a new 
order acceptance request, or to change the original order 
acceptance request in a different way. Client computer 12 
Q 15 and server 14 negotiate until the client is ready come to an 
~J agreement. At this point, client computer 12 ican enter the 

tV transaction phase of the electronic commerce transaction by 

E0 indicating in the client approval status information that if 

^ order acceptance request 16 is acceptable to server 14, the 

P 20 server should "capture" it for client computer 12. If order 
J: acceptance request 16 contains no violations of the server's 

y* acceptance criteria and the client approval status 

information indicates that the client desires the order 
^ acceptance request 16 to be accepted immediately, server 14 

25 will attempt to "capture" order acceptance request 16, 
thereby completing the electronic commerce transaction. 
There can also be other states of the client approval status 
information that will cause server 14 to attempt to capture 
order acceptance request 16 if it contains no violations of 
30 the server's acceptance criteria (for example, the client 
approval status information may indicate that the client 
desires immediate capturing of order acceptance request 16 
provided that the client's manager also approves). 
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The protocol described above enables an automatic 
negotiation of a commercial transaction between a buyer and 
a seller or between a client computer operating on behalf of 
a buyer and a server computer operating on behalf of a 
5 seller, where the server computer contains software that 
must enforce complex order acceptance criteria. The 
protocol enables the client computer and the server to 
efficiently negotiate toward a complete and acceptable order 
because the protocol communicates multiple acceptability 

10 criteria between the client computer and the server in each 
message. For example, order acceptance request 16 can 
contain multiple terms or conditions options to be filtered 
by the server, and order acceptance response 18 can contain 
multiple amendments indicating violations of acceptability 

15 criteria. Also, order acceptance response 18 can include a 
higher total order price that would be acceptable to server 
14 in order for server 14 to accept the terms or conditions 
of the original order acceptance request, or, alternatively, 
a lower total order price for compensating the client as an 

20 inducement for accepting different terms or conditions in 
order to avoid violating the acceptability criteria, and 
thus server 14 can implement order-dependent, negotiated 
hidden pricing. More generally, order acceptance response 
18 can include a plurality of various order prices 

2 5 corresponding to various terms or conditions of the offer. 

■Ap pend i x C cont ai ns jS2£cerp£-s^rom a manual 
■d escri bi na nnp implcmcn feHat a^ H o f Lhi j m1 -^^g new ^ pnmmg rr^ 
- syotom outlined ah o ^ep , 

As an example of one implementation of the protocol, 

3 0 in the negotiation phase of an electronic commerce 

transaction in which the client is a buyer (as opposed to 
the client being a party that interacts in turn with the 
buyer) , the buyer may click on a digital offer presented by 



a catalog server to the buyer as an HTML document on a web 
site, as described in the above-mentioned U.S. Patent No. 
5,724,424, and the buyer receives an order form that 
identifies the item the buyer might wish to purchase, its 
5 price, shipping choices, and payment choices. The buyer can 
provide billing information in blank boxes on the form, and 
the buyer might have the option of choosing a different 
shipper or a different payment instrument. The buyer can 
then click on a "recalculate" button on the order form which 
10 causes the buyer's order acceptance request 16, in the form 
of an order document indicating what the buyer would like 
the transaction to be, to be presented to the electronic 
commerce software . 
D By clicking on the "recalculate" button, the buyer 

P 15 causes the client approval status information in order 
Ul acceptance request 16 to indicate that the buyer seeks the 

2 server's opinion of order acceptance request 16, to be 

M expressed in the form of an order acceptance response 18 

E ^ including remarks from server 14. Alternatively, by 

O 20 clicking on a "buy now" button on the form, the buyer causes 
p the client approval status information to indicate that if 

tl order acceptance request 16 is acceptable to server 14, the 

l ;0 server should "capture" it for the buyer. 

H 

The negotiation phase is driven by the client (in 
25 the above case the client is the buyer) in that server 14 
cannot accept an order acceptance request 16 unless client 
computer 12 specifically requests that the server do so. 
If, for example, client computer 12 submits to server 14 an 
order acceptance request 16 in which the client approval 
3 0 status information indicates that client computer 12 

requests an order acceptance response 18 in the form of a 
quote or containing tax and shipping options, charges, 
payment choices, etc., server 14 cannot accept the client's 
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order acceptance request 16. On the other hand, client 
computer 12 can submit to server 14 an order acceptance 
request 16 in which the client approval status information 
indicates that if it is acceptable to server 14, the server 
may accept it by "capturing" it. 

Order acceptance request 16 and order acceptance 
response 18 are communicated in an extensible ^structured 
message format having a variable set of fields, such as XML 
(extensible markup language) or SGML. In one* embodiment the 
messages would be communicated between client computer 12 
and server 14 using a two-way-authenticated connection, for 
example an SSL connection using a shared key known to client 
computer 12 and server 14. Alternatively, identities can be 
established through the use of certificates. In other 
alternative embodiments order acceptance request 16 and 
order acceptance response 18 are encoded and decoded using 
well-known encoding and decoding techniques. Order 
acceptance request 16 and order acceptance response 18 may 
also contain information that has been digitally signed or 
authenticated^ The integrity of, modul ar eleme n ts of order 
acceptance request 16 and order acceptance response 18 can 
be separately protected by protection codes embedded within 
the protected modular' element . The protection codes can be 
implemented using digital signatures or message 
authentication codes or other well-known cryp^o.graphi.Q___ 
security techniques. The embedding of these codes within 
modular elements of the messages enables client computer 12 
and server 14 to efficiently store and forward the modular 
elements together with their protection codes. For example, 
an order acceptance request 16 may contain a digital coupon, 
protected by a protection code, that client computer 12 has 
obtained from a third party. Applications of such digital 



coupons in the context of electronic commerce system 10 are 
described in more detail below. 

The negotiation phase involves an exchange of 
documents that can contain a wealth of information. For 
example, an order acceptance response 18 to client computer 
12 can include a list of acceptable payment choices, a list 
of possible shipping options, error messages, the results of 
tax computations, and the result of shipping computations. 

The electronic commerce software automatically 
performs the functions of a seller during the negotiation 
phase. Because the software does not require a single 
module to handle all of the seller's functions, the seller 
can add its own modules to the software at will in order to 
cause additional negotiation functions to be performed. For 
example, a seller can add modules to the software that 
perform inventory control, fraud checking, rejection of 
orders to P.O. boxes, notification to fulfillment houses, 
etc . 

The architecture of the electronic commerce 
software, which runs on server 14, includes an order 
acceptance controller 20 and an order capture controller 22 
that exchange information with client computer 12. 

In an electronic commerce transaction in which the 
client is a buyer, server 14 may cause an order form HTML 
document to be displayed to a buyer by way of a web browser 
on the buyer's personal computer. The order form is an 
electronic representation of a paper form that can include 
empty spaces for the buyer's name, the buyer's billing 
address, the item or items to be purchased, the price for 
each item, the shipping method or methods preferred by the 
buyer, the payment method or methods preferred by the buyer, 
and so on, analogous to an order form from a department 
store catalog. Server 14 receives the completed order form 



and uses the information contained therein and the date to 
construct an order acceptance request 16 for consideration 
by order acceptance controller 2 0 and order capture 
controller 22. 

Order acceptance controller 2 0 and order capture 
controller 22 represent the seller. Order acceptance 
controller 20 is responsible for calculating or checking 
taxes, shipping methods, coupons, payment options (such as 
different credit cards, purchase orders) , etc., and order 
capture controller 22 is responsible for completing a 
transaction that has been accepted by order acceptance 
controller 20. 

In the above-described situations in which the 
client is a buyer, server 14 transmits order forms to and 
receives order forms from client computer 12 using software 
at server 14 that interfaces with order acceptance 
controller 20 and order capture controller 22 through an 
order entry API (application program interface) . It is also 
possible, however, for client computer 12 to interface 
directly with order acceptance controller 2 0 and order 
capture controller 22 through the order entry API, which 
specifies the protocol by which client computers and servers 
communicate about orders according to an agreed- to 
terminology. By virtue of this architecture, the seller or 
a third party is free to construct software at client 
computer 12 that interfaces with the order entry API and 
that allows a buyer to fill out an order form that can be 
very different from the order forms that happen to be 
provided by electronic commerce software (not shown in the 
figures) residing on server 14. This architecture 
accommodates sellers or third parties that don't like the 
order form provided by server 14 or who prefer to integrate 
the order composition process in a manner that does not even 



necessarily involve presenting an order form to the buyer. 
For example, the seller or third party might set up a 
question and answer interview with the buyer to create the 
order. 

Thus, the seller or a third party might want to 
provide a user interface to the buyer that is different from 
the user interface that can be provided by server 14 . The 
order entry API lets the seller or third party create that 
user interface. The seller or third party still must 
collect the same information that is requested by order 
acceptance controller 20 and order capture controller 22, 
but the seller or third party can choose to ask questions of 
the buyer in a different order, or can choose not to present 
some options to the buyer and instead pick the options on 
behalf of the buyer. 

For example, one implementation involves a 1-800 
number that a buyer can call and speak with an operator who 
acts as a proxy for the buyer. The 1-800 company functions 
as a client of the electronic commerce system. The operator 
might need to use an internal ordering system that is 
arranged in a particular format and that does not correspond 
with the default user interface. The seller can provide a 
different user interface to the operator of the 1-800 number 
by providing appropriate software at the client computer. 

If a buyer wishes to purchase a new automobile, for 
example, the buyer could call such a 1-800 number and place 
an order for a particular type of automobile. The client 
computer at the 1-800 company can automatically generate, 
based on the input from the buyer, one of a number of 
different order forms, depending upon the type of automobile 
selected by the buyer. The different types of order forms 
are compatible with different order acceptance controllers 
and order capture controllers operated by different 
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automobile companies. This arrangement allows a buyer who 
might be uncertain as to what type of automobile to buy to 
call an independent person whose service is to offer a one- 
stop location at which the buyer can propose offers on 
5 different types of automobiles manufactured by different 
companies . 

Likewise, a buyer might call a travel agency that 
can sell the buyer a hotel room, a plane flight, and golf 
times, and the travel agency (which functions as a client of 
10 the electronic commerce system) will parcel the information 
provided by the buyer into a number of separate orders that 
the travel agency sends to a hotel, an airline, and a golf 
course . 

O • Thus, the order entry API functions as a connection 

g 15 point where clients (such as the 1-800 company and travel 
yj agency described above) and sellers can meet in a manner 

2 that is independent of a particular user interface. There 

m can be many possible user interfaces that people can create 

~ on their own. For example, a consumer magazine company that 

p 2 0 evaluates products might decide to get into the business of 

allowing visitors to their web site to place orders for 
y ; products such as automotive vehicles. The consumer magazine 

company acts as a client of the electronic commerce system. 
^ Part of the value of the web site is to assist a buyer in 

25 deciding what to purchase. When the buyer has decided what 
to purchase, the web site can provide the buyer with an 
order form that has been custom tailored by the consumer 
magazine company. The order form allows a buyer to identify 
constraints such as: a vehicle that is four wheel drive, 
30 that is two-door as opposed to four-door, that is black, 
that gets certain gas mileage. The consumer magazine 
company's client computer can then communicate with order 
acceptance controllers and order capture controllers 
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maintained by different truck manufacturers by generating 
calls through the order entry API's of the manufacturers, in 
order to identify, through a negotiation process of the type 
described above, all of the possible options for the buyer 
subject to the constraints specified by the buyer. After 
the negotiation process is complete, the consumer magazine 
company can send an order to the vendor and get the vendor 
to actually accept the order . 

The client computer described above need not 
necessarily be operated by an agent for the buyer (in the 
case where the client is an entity other than the buyer) , 
but could instead consist of the buyer's own computer 
operating custom software sold by a vendor (in the case 
where the client is the buyer) . The electronic commerce 
systems does not require a seller to trust that the client 
computer is correctly calculating the terms and conditions 
for the order (such as the tax) , because those terms are 
enforced by the seller's server 14. The buyer's computer 
may choose to perform some of these calculations in order to 
provide a highly interactive and responsive user interface 
for a client, but in this electronic commerce system, those 
calculations are always double-checked (or enforced) during 
the order negotiation phase of operation of the seller's 
server 14 . 

Order acceptance controller 20 determines whether an 
order acceptance request 16 from client computer 12 is 
acceptable and sends an order acceptance response 18 to 
client computer 12, and order capture controller 22 accepts 
an order from a client computer 12 after the negotiation 
process is complete. When client computer 12 submits an 
order acceptance request 16 that requests an order 
acceptance response 18 or further information (for example, 
by virtue of a buyer clicking on a "recalculate" button) , 
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order acceptance controller 20 is run alone, but when client 
computer 12 submits an order acceptance request 16 that 
indicates that if order acceptance request 16 is acceptable 
server 14 should capture it for client computer 12 (for 
5 example, by virtue of a buyer clicking on a "buy now" 

button) , order capture controller 22 is run, which in turn 
calls order acceptance controller 20. 

Order acceptance controller 2 0 and order capture 
controller 22 include, in one particular embodiment, a 
10 specific series of predetermined steps combined with various 
points for call-outs 46 to optional custom modular plug- in 
components 24 and 26 that can be supplied by the operator of 
the software and that operate at server 14 or other servers 
■ y-' ■ connected to server 14 . ^ Appendix A includes source code 

q 15 interface definitions for the call-out points for this 
W particular embodiment. Plug-ins 24, 26 provide a modular 

acceptance pipeline for negotiating and capturing orders in 
ffl an efficient manner that accommodates the processing of 

^ detailed information concerning possible order acceptance 

p 20 violations. Plug-ins 24, 26 can interface with various 
+ databases 44 that store various rules, agreement terms, 

recent activity statistics, offer invalidity conditions, and 
"to do" instructions. Plug-ins 24, 26 use the information 
stored in databases 44 in formulating responses 48, to call 
25 outs 46. At each call-out point in order acceptance 
controller 20 and order capture controller 22, the 
controller either branches to a custom software plug-in 24, 
26 added by the operator of the software or, if there is no 
such plug-in 24, 26 the controller simply continues with the 
3 0 predetermined steps. There can be an arbitrary number of 

plug- ins 24, 26 at each call-out point, which can be called 
in an arbitrary order or in an order determined by 
programming of server 14. If a plug-in fails to respond or 
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responds by indicating that its operation has failed, order 
acceptance controller 20 or order capture controller 22 may 
respond to client computer 12 with an error notification or 
may re-try the call to the plug-in. In general, plug-ins 
5 performs functions such as preventing capture . of an order 
acceptance request until a later order acceptance request 
for the same order contains terms or conditions acceptable 
to the plug- in. The behavior of a plug- in, including 
whether the plug-in performs any function at all, and 

10 including its setting of terms or conditions (including 

prices) or its overall negotiation strategy, may depend on 
the content of the order acceptance request, including, for 
example, the presence or absence of certain types of 
coupons, specific information identifying a buyer or seller 

15 (authenticated or non-authenticated) or identifying a 

relationship between buyer and seller, specific types of 
goods, products or services, or specific terms or conditions 
specified in the order acceptance request. 

For example, with reference to FIG. 2, the seller 

20 can insert a restriction plug-in component 30 that performs 
inventory control. Thus, if a client proposes to purchase a 
particular model of an automobile in a particular color, and 
there is only one such automobile that is available, 
restriction plug- in component 3 0 might cause order 

25 acceptance controller 20 to send the client computer an 

order acceptance response indicating that the -automobile is 
available for a certain price and it will be reserved for 
the client computer as long as the client computer purchases 
the automobile within a certain amount of time. The plug-in 

30 component's response would be generated automatically based 
on some predetermined set of criteria. 

In other words, order acceptance controller 2 0 does 
not itself provide inventory control, but instead provides a 



gateway point in the middle of the program logic that allows 
the operator of the software to make an external call out to 
an item check restriction plug-in 30 to determine whether 
that inventory exists so that order acceptance controller 20 
5 may respond appropriately. If the operator of the software 
does not provide an item check plug- in 3 0 to order 
acceptance controller 20, on the other hand, order 
acceptance controller 20 will simply assumes that the 
product is readily available and will respond to a client's 
10 order acceptance request in accordance with a predetermined 
set of criteria that has nothing to do with inventory. In 
this case, if order acceptance controller 20 accepts an 
order from a client computer, the seller may need to notify 
S the client at some later point in time (by mail for example) 

p 15 of the availability or unavailability of the product. 
L 2 If the operator of the software does not install any 

^ restriction plug-ins, order acceptance controller 20 will 

CO operate as follows. When order acceptance controller 20 

receives an order acceptance request from a client computer, 
Q 2 0 order acceptance controller 2 0 performs an item check by 
J looking up the item requested by the client computer and its 

lI price and calculating the total amount due based on the 

JD quantity requested by the client computer. Then order 

m acceptance controller 20 processes any digital coupons that 

25 might be presented by the client computer, in accordance 
with the techniques described in U.S. Patent Application 
Serial No. 08/741,862, the entire disclosure of which is 
hereby incorporated herein by reference, filed October 29, 
1996 by James W. O' Toole, Jr. et al . and corresponding to 
^ 3 0 PCT Patent Publication WO$¥far9*r91 . Next, order acceptance 
controller 20 verifies the billing and shipping addresses 
specified by the client computer (for example, order 
acceptance controller 20 determines whether the U.S. Postal 
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Zip Code specified by the client computer matches the city 
specified by the client computer) . Order acceptance 
controller 20 then performs shipping computation, tax 
computation (computation of U.S. sales tax, Canadian tax, 
U.K tax, etc.), and then a payment check to ensure that the 
client computer has supplied an acceptable payment 
instrument. If the order acceptance request specifies 
multiple shipping methods or multiple payment methods that 
are acceptable to the client, order acceptance controller 20 
can select the shipping method or payment instrument most 
acceptable to order acceptance controller 20 (assuming at 
least one shipping method or payment instrument is indeed 
acceptable) . 

The operator of the software may arrange for a call 
to be made to one or more item check plug- ins 3 0 immediately 
before order acceptance controller 2 0 performs the standard 
item check. One type of item check plug- in 30 would be an 
inventory check plug- in as described above. Another item 
check plug- in 3 0 might modify the response of order 
acceptance controller 20 by, for example, factoring in a 
reduced per-unit price if the client orders a certain 
quantity of a particular item or modifying the order 
acceptance response to suggest to the client that the client 
might want to take advantage of such a reduced per-unit 
price by buying the requisite quantity. Likewise, item 
check plug- in 30 might factor in any special offers that 
might be applicable on a particular day, or might cause the 
order acceptance response produced by order acceptance 
controller 20 to identify a component that the client will 
receive for free if the client purchases a particular 
product, or might cause the order acceptance response to 
inquire whether the client wishes to purchase Product C 
given that the client has proposed to purchase Product A and 
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Product B, or might cause the client's order acceptance 
request to be rejected if the client is prohibited from 
ordering more than a certain number of a particular item and 
cause the order acceptance response to indicate the reason 
for rejection, etc. The behavior of the plug-in, including 
whether the plug- in performs any function at all, may depend 
on whether a coupon is present in the offer acceptance 
request or on the type of coupon that is present. 

After order acceptance controller 2 0 performs coupon 
checking and address checking but before it performs 
shipping computations, order acceptance controller 2 0 may 
call out to another plug-in 32 provided by the operator of 
the software. Ordinarily, a digital coupon object may be 
used by any party possessin g the coupon, as described i n the 
above-referenced U.S. Patent Application Serial No. 
08/741,862. The plug-in 32 may, however, reject a coupon if 
someone other than a particular person who is "authorized to 
use the coupon attempts to use the coupon, or if the coupon 
object contains a serial number to ensure it is used only 
once and the plug- in 32 determines that the coupon has been 
used previously, etc. The plug-in may be able to reject the 
coupon, for example, because the plug-in can know the 
identity of the client (because the client computer's 
authority has been authenticated, for example, by virtue of 
the use of a two-way-authenticated SSL connection) and the 
plug- in can know whether that client can be trusted to 
provide accurate information concerning the identity of a 
coupon holder. Alternative methods of identification of the 
client include basic authentication and client certificates. 

A plug- in 34 after the predetermined shipping 
computations can be used either to add or to subtract 
shipping choices, or to change the calculation of the 
shipping cost, or to place a call to a shipping company to 



obtain a tracking number to be included in the order 
acceptance controller's response to the client computer 
along with the date of shipment so as to allow the client to 
make inquiries to the shipping company. A plug- in 3 5 after 
the tax check can be used to perform some sort of general 
checking of the order acceptance request to ensure that the 
order acceptance request is acceptable, such as checking tax 
values and the total cost of the order. A plug- in 36 after 
the payment check can be used to perform some other sort of 
general checking of the order acceptance request, such as 
checking whether the proposed method of payment is 
acceptable for the item requested by the client. In 
general, each restriction plug-in can affect the results of 
previous steps only. Each restriction plug- in need not 
necessarily apply specifically to the results of immediately 
previous predetermined step alone, but could instead apply 
to the combined results of more than one previous step. 
Certain restriction plug- ins can be implemented with 
"restricted interests," so that they do not perform any 
function unless certain terms, conditions, or digitally 
authenticated objects are present in the order acceptance 
request. Order acceptance controller 20 encodes all of the 
comments and acceptability violations generated by the 
restriction plug-ins or order acceptance controller 20 into 
the order acceptance response, using standard error codes. 
The comments and acceptability violations serve as 
instructions for user-interface modules at the client 
computer in order to facilitate interactive ordering by the 
client computer by allowing the client computer to quickly 
correct the order to make it acceptable. 

One form of restriction plug- in 3 6 that can be 
implemented after the payment check step is an order- 
dependent fraud avoidance controller. As shown in FIG 3, 
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fraud avoidance controller 50 interfaces with a rules 
database 52 that contains various acceptability restriction 
rules as to which buyer classes are allowed to obtain which 
types of items and as to limits on the particular types of 
5 items that members of particular buying classes are allowed 
to purchase per period of time. Rules database 52 stores 
information pertaining to buyer identity, payment means, 
buyer network contact information (IP address, Email 
address, etc.), specific items being ordered, delivery 
10 address, and other seller-authenticated membership 

information, credit information, and relationship rating 
information supplied with the order acceptance request. 
Such information can be authenticated by the order 
O acceptance controller by authenticating a protection code 

^ 15 embedded within a modu lar^ element of the order acceptance 
y] request that contains the information. Fraud avoidance 

T controller 50 also interfaces with a rolling transaction 

ffi statistics database 54 in which fraud avoidance controller 

~ 50 stores information pertaining to each order in a 

p 20 statistical profile keyed by item, type of item, buyer 
± identity, buyer location, buyer pseudo-identity, buyer 

U cyberspace pseudo- location, or type of equipment or software 

£t used by the client source or transmission path, along with 

an indication whether the order was accepted, rejected, or 
25 processed to test acceptance prior to final buyer approval 
(fraud avoidance controller obtains information concerning 
acceptances and rejections from the failure notification 
module and capture notification module described below) . 
Fraud avoidance controller 50 compares each current order 
30 acceptance request to rolling transaction statistics 

database 54, and if the current order acceptance request or 
violates any maximum transaction rates as defined in 
restriction rules database 52, or otherwise violates any 
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transaction rule in restriction rules database 52, then 
fraud avoidance controller 50 logs an event in violation 
event log 60 and may also cause the order acceptance request 
to be rejected. 

When the client computer submits an order acceptance 
request 16 and indicates that if the order acceptance 
request is acceptable the server should capture it for the 
client, order capture controller 22 first causes order 
acceptance controller 20 to run to ensure that there are no 
problems with the order acceptance request. Then, if the 
response of order acceptance controller 20 indicates that 
the order acceptance request is acceptable, order capture 
controller 22 proceeds through three database sub- 
transactions . The first sub- transaction 80 is a pre- 
authorization call to a custom capture plug-in 38 supplied 
by the operator of the software that might do some sort of 
expensive checking procedure that the operator of the 
software does not wish to perform during the order 
acceptance process. The pre-authorization call is followed 
by writing the order acceptance request into a database(^39^ 
if the results of the checking procedure performed by plug- 
in 38 are favorable or by calling a failure notification 
plug-in 56 to provide notification that the order acceptance 
request has failed. The second sub- transaction 82 involves 
a call to a payment processor 28, such as the processor of a 
credit card company, to obtain authorization for the overall 
transaction, in the manner described in the above-mentioned 
U.S. Patent No. 5,724,424. The client may be able to select 
the payment processor that is used by identifying its 
preferred payment method (for example, a particular credit 
card company) in the order acceptance request, provided that 
the preferred payment method is acceptable to the server. 
In the third sub-transaction 84 performed by order capture 
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controller 22, if the overall transaction is not authorized 
by the payment processor, or if any capture plug- in 3 8 
generates an acceptability violation, order capture 
controller 22 marks the transaction as being failed, calls 
5 out to a failure notification plug-in 56 indicating that the 
order failed, and encodes any comments and acceptability 
violations generated by capture plug- in 38 or order capture 
controller 22 into an order acceptance response to the 
client computer, using standard error codes. If the 

10 transaction is authorizedv by the payment processor, order 
capture controller 22 may mark the transaction as being 
captured, call out to a capture notification module 58, and 
notify the client computer in an order acceptance response. 
Alternatively, if the transaction is authorized by the 

15 payment processor, order capture controller 22 may call out 
to a custom capture plug-in 40 supplied by the operator of * 
the software that can perform additional checking over what 
the payment processor does, to provide a higher level of 
security. If custom capture plug-in 40 rejects the 

20 transaction, order capture controller 22 marks the 

transaction as being failed, calls out to the . failure 
notification module 56, and notifies the client computer as 
described above. If custom capture plug-in 40 accepts the 
transaction, order capture controller 22 places the order in 

25 a capture state, calls out to the capture notification 
module 58, and notifies the client computer. 

Each of sub-transactions 80, 82, and 84, at the end 
of its processing, either "commits" if processing has 
proceeded successfully, which terminates the processing of 

30 the sub-transaction, or "rolls back" if there has been some 
sort of problem with the processing, in which case the sub- 
transaction attempts to begin its processing again. This 
architecture minimizes the potential of locking of databases 
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that are accessed by order capture controller 22, because 
only a portion of the overall processing of order capture 
controller 22 actually repeats itself in the event of a 
problem. 

Failure notification and capture notification is 
useful because, for example, there are two ways to do 
inventory reservation. One method is to reserve inventory 
during the order acceptance process and to subject it to a 
time window. Then when the client computer requests an 
order capture during the time window, the capture 
notification module 58 notifies the reservation system that 
the time window is no longer applicable and the product is 
really going to be purchased. Another method is to perform 
a tentative reservation during the order acceptance process 
or at the top of the capture order process and then if the 
order is not captured the failure notification module 56 can 
notify the reservation system that the reservation should be 
cancelled . 

Capture notification plug- in 58 is advantageous in 
that, for example, the plug- in can be supplied by a seller 
of newspaper subscriptions and may update a subscription 
table 43 that lists periodicals to which a person has 
access. A subscription table 43 keeps track of the 
newspapers and periodicals to which a particular person has 
access and keeps track of when the access expires. 
Newspapers and periodicals can use the subscription table 43 
to control access to subscription content, by inquiring 
whether a particular person has a subscription that has not 
expired. If the subscription table 43 indicates yes then 
the newspaper or periodical will grant access, but if the 
answer is no then the newspaper or periodical can inform the 
person that access has been denied and inquire whether the 
person wishes to subscribe. 



Micro- transaction purchases can be handled by order 
capture controller 22 using such a subscription table 43. 
If a client wishes to initiate a subscription to a certain 
periodical or newspaper at a charge of a certain price per 
5 page or article, for example, the client can cause a fixed 
amount to be paid, and every time the web page of the 
periodical or newspaper is visited an account will be 
decremented by the price per page or article. The initial 
payment can be handled by order acceptance controller 20 and 

10 order capture controller 22, and then a capture notification 
plug- in 58 increase the number of tokens in a token database 
41 that are available for use in exchange for reading of 
each page or article. When the web page of the periodical 
or newspaper is visited by the party from whom the fixed 

15 amount was paid, the number of tokens in the token database 
41 is decremented. In this manner the electronic commerce 
system can provide a cheaper result for an individual who is 
interested in only a small portion of a periodical or 
newspaper, as opposed to paying a blanket amount for the 

2 0 right to read the entire periodical or newspaper. 

After the authorization has been completed, a final 
call-out is performed to a custom post-capture plug-in 42 
supplied by the operator of the software that can cause 
functions such as sending of e-mail or any other activity 

25 that should be performed only after the transaction has been 
captured. Because post-capture plug-in 42 operates after 
sub-transaction 84 has been completed, it is useful for 
performing functions that consume large amounts of time, 
without affecting the capture process. 

30 One implementation of the digital coupons discussed 

above involves gift certificates. The use of gift 
certificates involves selling the gift certificate and 
redeeming the gift certificate. In the selling phase, a 
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merchant client computer creates an order acceptance request 
that includes extension information indicating that the 
order is a gift certificate for the item requested by the 
client computer. The order acceptance request is processed 
in the ordinary manner described above, and when the order 
acceptance request is captured, a po^i-capixLce plug-in of 



order capture controller 22 createsVa^serial number for the 
gift certificate and places it in a database along with its 
price and sends the client computer the gift certificate, 
10 which is a digital coupon that includes the serial number. 
The purchaser of the gift certificate can then transmit it 
to a recipient. 

In the redemption phase, the recipient can click on 
S an icon of the gift certificate and the recipient will 

g 15 receive a web page of a merchant that sells the product. 
Lf1 The recipient receives an order form and initiates an order 

IP 

77 acceptance request. Plug- in 32 processes the gift 

Eg certificate as part of the coupon checking step in the 

— manner described above and ensures that the serial number of 

p 20 the coupon has been used only once by checking the database 

=F in which the serial number is stored. 

With reference to FIG. 4, another implementation of 
the electronic commerce system involves a virtual warehouse 
system. According to this concept, a merchant 65 can 
25 contact a virtual warehouse server 63 through an internet 
browser and can store a virtual inventory of items for 
storage in a database 64 that is accessed by item check 
plug-in 61 (an example of an inventory control plug-in 30 in 
FIG. 2) through a call to virtual warehouse server 63. 
30 Merchant 65 might, for example, provide this information 

every morning after examining the supply of various items in 
the merchant's store. The merchant would reserve a fraction 
of the actual supply of each item for sale within the 
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merchant's physical store and allocate the remaining 
f racti on to the virtual warehouse by storing the inventory 
of that remaining fraction in database 64. Then, when plug- 
in 61 performs inventory control, plug-in 61 checks database 
5 64 to ensure that the item or items requested by the client 
are included in the merchant's virtual inventory, and plug- 
in 61 modifies the inventory accordingly. 

According to the concept of a virtual warehouse, a 
small or medium enterprise places a portion of its inventory 

10 under the management of the virtual warehouse, which can 

then make commitments to customers against that allocation. 
For example, a small seller of widgets may create a Web- 
based catalog. Since the market for widgets depends on 
immediate gratification of buyers, it is important to assure 

15 availability. Each business day, the seller uses an 

administrative Web application to grant control of a certain 
number of widgets to the virtual warehouse. When a buyer 
browses the widget catalog, the catalog system uses a real- 
time query to the virtual warehouse to obtain the number of 

20 widgets on hand. The catalog uses the quantity obtained to 
control its behavior, selecting regular or promotional 
pricing. When a buyer selects a widget for purchase, the 
catalog system obtains a reservation against inventory from 
the virtual warehouse. The reservation is good for a fixed 

25 time such as thirty minutes. The idea is similar to the way 
airline reservations work. The reservation is good for a 
fixed time, and lapses if the tickets are not paid for 
before the reservation expires. When the transaction 
commits before the reservation expires, the Internet 

3 0 commerce transaction system records that fact with the 

virtual warehouse, confirming the reservation and removing 
the appropriate widget count from the allocation. During 
the day, or periodically, the seller can add or remove 



inventory from the virtual warehouse, although inventory 
cannot be removed if held by an active reservation. 

In this way, a small enterprise can obtain the 
benefits of a fully integrated inventory management system 
5 without great expense. The virtual warehouse is merely a 
debit, credit, and reservation system for paper inventory, 
but the customer is happy because the customer can obtain a 
guarantee of delivery. 

The virtual warehouse breaks down only at the 
10 margins: if not all inventory is entered in the virtual 

warehouse, then some customers may not be able to order when 
in fact supply is available. However, a customer is never 
promised delivery when inventory is not available, 
p The virtual warehouse 63 is built around a database 

. 15 64 that stores items, inventory, and reservations. Around 
in that database are the applications that interact with it on 

HP behalf of catalog systems 74, transaction systems 10 (such 

ft* as the electronic commerce systems described herein) , 

□ merchants 65, ERP systems 62, and administrators 78. 

p 20 With reference to Fig. 5, one implementation of 

jp; another restriction plug-in 34 is a shipping restriction 

J=J handler. For certain types of orders, the shipping choices 

2 may be limited by the details of the order. For example, an 

ffl order containing certain types of hazardous materials may 

25 have a limited number of shipping choices. An order 

specifying a Saturday delivery to a remote location may have 
no shipping choices available. 

During the negotiation phase, an order acceptance 
request is routed to shipping restriction plug-in 34, which 
30 passes the order acceptance request to shipping restriction 
rules calculator 68 , which figures out which shipping 
choices are valid for the order. The rules may use a 
shipping item attributes database 70 that specifies certain 

- 28 - 



shipping-related properties for items in the order. For 
example, shipping item attributes database 70 would specify 
that nitric acid is in a certain hazardous materials class. 
Alternatively, the shipping item attributes could be 
contained in the order or item descriptions and need not be 
looked up in database 70. 

Shipper availability database 72 specifies which 
shippers are available for certain types of orders. For 
example, it would specify that a particular courier ships to 
a particular remote region on Monday through Friday, for 
non-hazardous materials only. Based on this availability, 
shipping restriction rules calculator 68 would not offer 
that particular courier as a shipping option for an order 
specifying Saturday delivery in that region, or for any 
order containing hazardous materials shipped to that region, 
or for both. 

Once shipping restriction rules calculator 68 has 
determined the list of available shippers for the order, 
that list as well as optional shipping choice meta-data is 
returned to shipping restriction plug- in 34 for 
incorporation into the order acceptance response. The list 
of available shippers may be empty, which means to the 
client that the order is not shippable. The list of 
available shippers may be one, which means that the client 
does not have a choice. Or, the list of available shippers 
may be more than one, which means that the client may choose 
from any of the offered shipping choices. In all cases, the 
optional shipping choice meta-data provides descriptive text 
for the buyer about why the shipping choices may be 
restricted . 

There have been described novel and improved 
electronic commerce systems. It will be apparent to persons 
skilled in the art that numerous modifications of and 
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departures from the specific embodiments described herein 
are possible without departing from the scope of the 
invention as defined in the claims. 
What is claimed is: 
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